Terminals, such as smartphones or personal computers (PCs) are nowadays capable of activating and using a plurality of logic interfaces associated with one or more physical interfaces. Such terminals are said to be multi-interface (MIF) terminals.
A plurality of IP addresses can be allocated to such MIF terminals so that they can connect to different types of network such as a fixed network, a mobile network, or a wireless local area network (WLAN), where the emblematic example would be a WiFi network, and in a manner that may be simultaneous or deferred. These IP addresses may:                belong to the same family of addresses or to different families of addresses (IPv4, IPv6, or both);        have different lifetimes;        have different scopes, e.g. a private IPv4 address, a unique IPv6 address of local scope (i.e. a unique local address (ULA)), or an IPv6 address of global scope (global unicast address (GUA)); and        be allocated to the same logical network interface or to different logical network interfaces.        
Nevertheless, it should be observed that the “MIF” characteristic is volatile, since the ability to use a plurality of interfaces depends on conditions of connection to the network(s), on the location of the device, or on other factors. An MIF device may in particular make use of a plurality of interfaces that are available to it while setting up a simple connection (i.e. a connection set up along a single path with a given third party), or after setting up a simple connection. It may also be observed that a device does not know a priori whether it has the possibility of using a plurality of distinct paths for setting up a connection with a given third party. More precisely, the device acquires this information (where appropriate) only at the end of a stage during which it attempts to set up a multipath connection with the third party.
When a terminal has a plurality of interfaces capable of connecting to different access networks (e.g.: fixed, mobile, or WLAN), it then benefits from access that it said to be “hybrid”, since it combines different access network technologies. The services on offer concerning a terminal having hybrid access rely on introducing functions in the network that make it possible to aggregate all of the network connections of a terminal (e.g.: WLAN and 3G, or ADSL, WLAN and 4G).
In this respect, it should be recalled that in the field of networks, the term “link aggregation” designates grouping together a plurality of links that are associated with a corresponding number of “logical” interfaces as though they were a single link associated with a single interface, in particular for the purpose of increasing data rates beyond the limits of a single link, but also for applying the same operating procedures to all of the links aggregated in this way (a concept referred to as “fate sharing”). Link aggregation may optionally also ensure that other interfaces take over if a network link should fail (redundancy principle). Link aggregation applies to any type of traffic conveyed over such links, including IP traffic.
Link aggregation could also be used for spreading traffic over a plurality of links. Under such circumstances, the spreading of traffic over the links that make up an aggregate depends on various parameters; the spreading of traffic may depend for example on the type of traffic, such as transmission control protocol (TCP) or user datagram protocol (UDP), or on the traffic engineering policy, such as the required quality of service (QoS).
By way of example, FIG. 1 shows a terminal T connected to a server S via a plurality of IP networks referenced R1, . . . , Rm and O, by implementing the multipath TCP (MPTCP) connection protocol. The various access networks R1, . . . , Rm may be of wired, wireless, or other natures; furthermore, these accesses may be multiple, i.e. the terminal T may have the capacity to connect to different access networks optionally in simultaneous manner.
Likewise, FIG. 1b shows a terminal T compatible with MPTCP or only with TCP, and located behind a piece of equipment referred to as a proxy R; the proxy R is itself connected to a server S via a plurality of IP networks written R1, . . . , Rm, and O, implementing the multipath TCP connection protocol (MPTCP).
In general manner, the term “proxy” is used to designate a piece of equipment located in the network and acting on behalf of one or more user equipment, such as a terminal or a gateway. This configuration enables the user equipment to benefit from optimized use of available network resources, and also to establish multipath connections quickly.
It should be observed that link aggregation makes no assumptions about the configuration of the remote machine. Thus, a source machine may activate a link aggregation function without the remote machine using such a function.
Various modes of aggregation may be envisaged, including the following three modes:                backup mode: this mode consists in using secondary paths in the event of primary paths being unavailable, with this being for the purpose of improving the availability of the network and thus the robustness and the reliability of IP connections set up over the various links;        bonding mode: this mode consists in using the resources associated with some or all of the available paths, the IP streams associated with a given application possibly being spread over a plurality of paths; the decision to use all of the paths, or only some of them, may for example be conditioned by the nature of the traffic or the availability or reliability characteristics associated with each path, which characteristics may vary greatly from one path to another; all of the paths selected for this bonding mode are considered as being primary paths; and        a “comfort” mode: this mode is similar to the bonding mode, except that the streams of a given application are not spread over a plurality of paths, but are sent over a single path.        
It should be observed that these modes are not mutually exclusive, and that they are not specific to any one particular type of traffic. Thus, they may be put into place independently of the nature of the traffic that is to be conveyed along paths aggregated in one or another of the various modes.
Nevertheless, using multiple paths for setting up communications raises problems of various kinds.
It is commonly accepted that the use of load sharing mechanisms between a plurality of paths needs to ensure that those paths possess a comparable level of quality of transfer, in particular so as to avoid weakening the integrity of the data that is characteristic of a given connection and that is exchanged over those various paths (the quality of transfer may be characterized by a plurality of parameters including, in particular: latency, jitter, and/or rate of packet loss).
When a terminal benefits from hybrid access, its actual ability to make use of all of its interfaces is generally associated with the quality of each of the access networks in question, as perceived by the terminal, or by an application that is active in the terminal. This quality may be expressed in terms of available bandwidth, or of time to access the desired resource, or indeed in terms of variation in transmission delay, as specified in Document RFC 3393 of the Internet engineering task force (IETF). This quality naturally varies from one access network to another, and may present considerable disparities that could compromise setting up a multipath communication over the various access networks; the risk of a loss of integrity of the streams exchanged during the communication increases with any increase in such differences, to such an extent that the communication might become unintelligible. Furthermore, this disparity varies over time, e.g. as a function of the level of utilization of the resources of a network. The quality of the aggregated link also depends on the locations and the effectiveness of the network functions that enable of the network connections of a terminal to be aggregated.
These different quality levels can compromise setting up additional subflows in the context of a multipath connection. The magnitude of the above-mentioned risk of loss of integrity might incite the terminal to set up a simple connection only, even though that means losing the benefit characteristics of a multipath connection, such as optimizing available bandwidth resources or preserving continuity of a connection in the event of loss of attachment to a first network and re-attachment to a second network.
Such a risk is also made worse in the context of a terminal that does not have its own means enabling it to set up a multipath connection, and doing this by calling on a proxy such as the device described briefly above. In this context, the question of disparity between the quality levels associated with using a plurality of available proxy-functions (e.g. depending on the location of the remote terminal with which the terminal seeks to set up a communication) becomes correspondingly more complex to solve when the terminal does not necessarily have the information and the intelligence required for selecting the proxy that presents the best guarantees of quality, e.g. depending on the nature of the traffic, of the application, or of the service associated with the communication.
Furthermore, at present, multipath protocols have not yet been adopted in generalized manner by content servers. Thus, some content servers process multiple connections as disjoint connections, and do not have a mechanism enabling them to correlate a plurality of connections in order to associate them with a single terminal, which has the unfortunate consequence of preventing any attempt at setting up a multipath connection, as shown in FIG. 2a. 
As shown in FIG. 2b, this problem of a server being incompatible with multipath connections has an impact on the effectiveness of the communications of any terminal seeking to communicate with such a server, whether the terminal is connected directly to the network or via a proxy.
In order to assist terminals, residential gateways (e.g. home or business gateways), set-top boxes, or other user equipments in setting up and maintaining connections via multiple paths, IP connectivity suppliers make use of devices referred to as “network connection concentrators”. A “network connection concentrator” designates any network function making it possible to aggregate connections making use of different paths that might be used by a device in order to set up a communication with a remote device.
By way of example, a network connection concentrator (the term “concentrator” on its own is used below for reasons of concision) may be a function in a residential gateway, or it may cohabit with an MPTCP or with a stream control transmission protocol (SCTP) proxy-function, or with a generic routing encapsulating (GRE) tunnel termination point, or indeed may be a termination point of IP-in-IP tunnels or of level 2 tunnels. Where appropriate, the aggregation of all the multiple paths by a concentrator may give rise to one or more virtual tunnels being set up, e.g. in order to facilitate management operations associated with setting up the communication (by isolating the traffic characteristic of the communication set up over the various paths that have been aggregated in this way, and by improving the process for detecting failures).
As examples, FIGS. 3a, 3b, and 3c show various types of architecture associated with network connection concentrators.
These figures show a terminal T connected to one or more IP networks R1, . . . , Rm or O via N nodes (P1, P2, . . . , PN) having a network connection concentrator function. By way of example, such a node may be a gateway (home or business) or an IP router. In the figures, it can be seen that:                the terminal may be connected to a single network O managed by a single IP connectivity supplier that has deployed at least one network connection concentrator (FIG. 3a); or        the terminal may be connected to m networks R1, . . . , Rm, all hosting at least one network connection concentrator (FIG. 3b); or indeed        the terminal may be connected to m networks R1, . . . , Rm, some of which host a plurality of network connection concentrators (FIG. 3c).        
Advantageously, intervention by a network connection concentrator has the particular effect that a connection that is seen by a local device as being a multipath connection may be seen by a remote device as being a plurality of simple connections, as shown in FIG. 4a. 
Nevertheless, even in the presence of one or more concentrators, additional problems arise. In particular, as shown in FIG. 4b, certain connections (e.g. TCP connections) of an aggregate will be rejected by a remote device since it is incapable of correlating the various connections in order to process them as an aggregate connection sent by one and only one user equipment, since the messages reaching the remote device present different source addresses (@IP_1, @IP_2, . . . , @IP_N).
A first approach consists in ensuring that each terminal uses only one address as the source address of the packet that it sends over all of its access networks. However that approach is not a good solution to the above-mentioned problem, since access networks activate mechanisms for verifying source addresses in order to avoid prefixes being pirated and usurped (known as “anti-spoofing” mechanisms). Thus, packets sent with an address other than the address allocated by the access networks are rejected by the access network (since they are taken to be attempts at stealing addresses).
Naturally, that risk of piracy could be minimized or reduced to zero if coordination were put into place between the operators of various access networks, or in the event of the various access networks being managed by the same network connectivity operator. However coordination between various access network operators for allocating a single address and/or a single prefix to a terminal is not realistic. As for the single operator assumption, it is restrictive since, in a conventional deregulation context, terminals have the possibility of using networks that are not managed by the same operator. In addition, ensuring the same addressing policy for all of the access networks operated by a given operator gives rise to considerable engineering, or indeed organizational implications; specifically, the reality of deployment influenced by regulatory constraints, and also by conditions for allocating address blocks, and guided by the desire to ensure deployment flexibility at network segment level (e.g. fixed and mobile), is such that so-called “convergent” operators use different addressing plans for the different access networks that they use.
Another approach consists in deploying one and only one concentrator, with the packets sent via all of the access networks being intercepted by the same concentrator. This approach likewise presents serious drawbacks, as set out below.
A first variant consists in activating routing mechanisms in each access network in order to redirect traffic towards said concentrator. To do this, the access network needs to inspect all of its traffic, which requires complex functions of each packet inspection (DPI) type.
Furthermore, this solution is not appropriate if a load sharing mechanism is activated by the network hosting the concentrator function (e.g. if the allocation of a concentrator to serve a terminal is performed during attachment to the network), since the traffic engineering policies of access networks that do not host the selected concentrator need to be adjusted dynamically in order to take account of constraints in another network, which would be extremely complicated to implement.
A second variant consists in having recourse to an encapsulation mechanism (e.g. GRE or IP-in-IP) in order to force packets to pass via a single concentrator, regardless of the access network used for sending the packet. However encapsulation introduces additional complexity and, as a function of the encapsulation scheme used, that can go so far as to cancel the positive effects of a link aggregation mechanism. Encapsulation is also liable to degrade significantly the switching performance of the equipment terminating the set of GRE or IP-in-IP tunnels and also housing the concentrator function. Furthermore, problems of passing through network address translators (NATs) and firewalls can be encountered when using certain encapsulation mechanisms and when restrictive filtering rules are configured on a NAT or on a firewall placed in one or more multiple paths. Finally, the quality of multipath communications would depend not only on the location of the concentrator, but also on the performance of the various access networks used to reach the concentrator, and the quality of experience (QoE) as perceived by the user of the user equipment would depend on conditions of connection to the various networks.